This invention relates to a mapping-type optimization system for reducing computer-network data traffic between (1) an arbitrary host unit, such as a VTAM application program, which issues SEND- and RECEIVE-type instructions to a communications manager such as VTAM; and a peripheral unit such as a remote terminal. In part, the invention represents an advantageous generalization of mapping-type optimization systems taught in U.S. Pat. Nos. 4,750,137; 4,837,679; 4,937,739; 5,005,137; and 5,046,025. all assigned to the assignee of this application.
Program Operation in the VTAM Environment
VTAM (Virtual Telecommunications Access Method) is a collection of computer program routines and macros that facilitate Systems Network Architecture (SNA) communications. VTAM is distributed by IBM and widely used on IBM-type mainframe computers. VTAM is described in detail in, among other places, the publication "Advanced Communications Functions for VTAM," published by IBM under its catalog number SC23-0015 (updated periodically; hereinafter referred to as the VTAM Manual). Some of the pertinent functions of VTAM are summarized herein, but it is assumed that those of ordinary skill having the benefit of this disclosure will be familiar with the VTAM Manual or with the information set forth therein.
Nature of VTAM. Referring to FIG. 1B, VTAM provides callable communication services to application programs that have been designed to make use of such services. Such application programs are commonly referred to as "VTAM applications" and sometimes as "APPLS" (pronounced apples) or colloquially "APPLIDS" (apple-eye-dees). A VTAM application generally comprises two portion, the processing portion and the communications portion.
The processing portion of a VTAM application is largely arbitrary. It performs whatever processing (e.g., database manipulation) is desired by the application designer. It can normally be written in any convenient computer language for which a compiler, interpreter, etc., is available.
The communications portion, normally written in assembly language, handles the application's interface with VTAM and thus with the computer system's communications facilities. The communications portion takes care of:
(1) establishing itself as a VTAM application, i.e., registering with VTAM as a user of VTAM's communications services, usually by issuing macro instructions such as OPEN to VTAM as discussed in more detail below; PA1 (2) handling requests from other logical units, conveyed by VTAM, to establish a communications session with the application program; PA1 (3) sending information to, and receiving information from, other logical units via VTAM's communications services, normally by issuing macro instructions such as SEND and RECEIVE to VTAM; and PA1 (4) when necessary, de-establishing itself as a VTAM application, normally by issuing macro instructions such as CLOSE to VTAM. PA1 (i) specifying just what service is desired, as well as additional control information, in one or more addressable storage "message boards" that are accessible to both the VTAM application and VTAM itself, and PA1 (ii) passing control to a special routine in VTAM itself that, among other things, goes and looks on the message board(s) to determine what action should be taken. PA1 (a) intercepting the outgoing signal; PA1 (b) generating an updated-state map of the buffer as it is expected to exist after the LU's receipt of the outgoing signal, PA1 (c) comparing the updated-state map with a previously-created and -saved present-state map of the buffer to generate a difference map, and PA1 (d) generating a substitute outgoing signal that repaints only selected portions of the terminal screen, e.g., those portions that would actually change as a result of the outgoing signal.
A greatly simplified representation of typical data flows in a SEND request issued by a VTAM application is depicted in FIGS. 1A and 1B. The syntax and other conventions by which the communications portion of an application program interfaces with VTAM is sometimes referred to as the "VTAM application program interface (API)."
As seen in FIG. 1B, in step (a) the application APPL writes outgoing data to be sent to, e.g., a terminal to a buffer. In step (b), the APPL issues a SEND macro instruction to VTAM; in step (c), VTAM retrieves the outgoing data, and in step (d) VTAM sends the outgoing data to the terminal.
Public Library Closed-Stacks Analogy. For purposes of illustration, an analogy to a public library is used below and depicted in FIG. 2. Many public libraries have at least some closed-stack reserved book areas that are accessible only to library staff. Patrons wishing to get books, magazines, etc., from such an area typically must fill out request slips and turn them in to a staff member (referred to here as a "dispatcher") at a service desk located in a publicly accessible area. The dispatcher collects the request slips and passes them, either immediately or periodically in a batch, to other library staff members working in the closed stacks (referred to here as "researchers").
The dispatcher at the service desk is analogous to VTAM, in that he or she serves as an intermediary, a communications interface, between the library's closed-stack researchers and the library's patrons. The researchers working in the closed stacks are analogous to VTAM applications, because they deal with library patrons only via the dispatcher at the service desk.
The above analogy will be referred to from time to time in the discussions below. It must be understood, of course, that the analogy is only a rough one and is presented solely as an aid to understanding.
Issuance and Completion of VTAM Macro Instructions. As is well-known in the art, generally speaking VTAM applications request communication services from VTAM by:
At some point in its processing of the service request, VTAM returns control to the VTAM application. In doing so, it likewise "leaves a note" for the application in one or more message boards to indicate the status of the request processing.
Depending on the nature of the service request, control may be returned to the VTAM application upon completion by VTAM of all steps necessary to process the service request. This is commonly referred to as "synchronous" processing.
Alternatively, control may be returned to the VTAM application earlier than such completion, and generally as soon as VTAM has accepted the request for processing. This is commonly referred to as "asynchronous" processing. The VTAM application and VTAM itself each continue execution more or less in parallel as determined by the operating system of the computer system in question. VTAM reports completion of the service request by leaving a note to that effect for the VTAM application, then passing control to a special routine in the application.
In the library analogy, a closed-stacks researcher may leave a message to the dispatcher on the library staff message board, asking the dispatcher to give certain books to a library patron, and then call out the dispatcher's name to let the dispatcher know that there is work to be done. The dispatcher reads the message, complies with the request, and leaves a return note on the message board, addressed to the researcher, reporting that completion.
In synchronous processing, the researcher would not go back to work until he read the dispatcher's completion report on the message board. On the other hand, in asynchronous processing the researcher would go back to work as soon as he saw the dispatcher read the service-request message on the message board. The researcher would go back to the message board to read the dispatcher's completion report only when his (the researcher's) own name was called for that purpose.
Request Parameter List (RPL) "Message Board". Many kinds of VTAM macro instructions must indicate the address of a "request parameter list" or RPL. The RPL operates as a message board of the kind described above. Its format is described in detail in the VTAM Manual; and its operation can usefully be explained through the library analogy.
Suppose that a closed-stack researcher John Doe (analogous to a VTAM application program) retrieves several bulky books, several pages of which are to be photocopied and delivered to library patron Jane Roe (analogous to a logical unit LU). Further suppose that researcher Doe will not carry these books to the photocopy service area himself, but instead wants the dispatcher (analogous to VTAM) to do so and also to deliver the copies to patron Roe.
John Doe writes out these instructions for the dispatcher, including the fact that the photocopies are to be delivered to patron Jane Roe. Instead of attempting to deliver the specific instructions directly to the dispatcher, John Doe leaves the instructions in, say, pigeonhole number 432 shown in FIG. 2. He then writes a separate, very short note on the library staff message board saying only that there is photocopy work to be done, and that more detailed instructions are located in basket number 432. These more detailed instructions (i.e., control information) and the numbered basket are analogous to an RPL and its address.
John Doe calls the dispatcher's name to get his attention and points at the message board; the dispatcher, perhaps operating in accordance with a priority scheme of some sort, eventually retrieves the detailed instructions from pigeonhole number 432. This frees up researcher John Doe to go back to work if he so desires (thus an example of asynchronous processing; as noted above, John Doe may instead elect to wait around for the dispatcher to report completion of the task, referred to as synchronous processing).
Normal OPEN Processing by VTAM
As alluded to above, a VTAM application commonly establishes itself as a user of VTAM's communication services by issuing macro instructions such as OPEN. An OPEN instruction is analogous to closed-stack researcher John Doe announcing his arrival for work at the beginning of a shift.
The OPEN instruction specifies certain things to VTAM so that VTAM knows what to do in specific situations. This is analogous to the closed-stack researcher John Doe locating an empty desk and signing in on a chart indicating that he will be working at that particular desk today. This sign-in procedure permits the dispatcher to determine where requests that are to be passed specifically to John Doe should be routed.
As shown in simplified form in FIG. 3, in the same vein the VTAM application constructs an access method control block (ACB) and an exit list (EXLST) in addressable storage (step (a)). The formats of these two control blocks are described in detail in the VTAM Manual and are briefly described below.
The access method control block ACB constructed by the VTAM application is an area of addressable storage that is used by both VTAM and the application. The ACB conforms to the conventional VTAM format; that is, the order and type of data in the ACB storage area conforms to a set of rules so that both the application and VTAM can identify and access the ACB data, which are used primarily to identify the application to VTAM. The ACB includes a pointer to the exit list EXLST, shown in FIG. 3 as A(EXLST).
In the library analogy, the ACB corresponds roughly to the part of the researcher sign-in chart that identifies the desk at which researcher John Doe will be working during his shift.
As illustrated in FIG. 3, the exit list EXLST serves as a "card catalog" containing the locations of procedures to be performed upon the occurrence of specified events. The exit list EXLST is an area of addressable storage that contains the names of (or addresses other pointers or references to) any "user exit points" previously established by the application. These are shown in FIG. 3 as A(ATTN), . . . A(TPEND). Each user exit point is a program (routine) to which control should be passed by VTAM upon the occurrence of a specified event. For example, in all likelihood the application will include a routine to be given control upon the occurrence of a request to establish a session by an end user at a terminals. The exit list EXLST for such an application would normally contain a reference to a LOGON exit to which control should be passed upon such an occurrence.
In the library analogy, suppose that the closed-stack researcher John Doe is, among other things, conducting an end-user survey to help determine how the library's Russian literature collection might be improved. Toward that end, he wishes to make photocopies of all Russian-literature request slips submitted by library patrons for his later use in this project, and has left detailed instructions with the library's photocopying staff in this regard.
When John Doe signs in for a shift, he might specify, in a special block of the sign-in chart, that whenever the dispatcher desires to route a request slip to him that involves Russian literature, he (the dispatcher) should send the request slip to the photocopying service area to be copied. Clearly, John Doe need not write out, in his space on the sign-in chart, the detailed instructions that he has already left with the photocopying staff; he need only indicate in that space that certain request slips are to be photocopied in the photocopy service area in accordance with the procedures that he has already specified in that area.
This special block on the library sign-in chart thus contains a "pointer" to the photocopying service instructions desired by John Doe upon the routing of a Russian-literature request slip to him. This block is analogous to an application program's exit list EXLST, which includes pointers to user exit routines to which control is to be passed by VTAM upon the occurrence of specified events.
Establishment of VTAM Sessions by APPLs
After a VTAM application program has successfully signed in for work, so to speak, with VTAM, the application can establish one or more work sessions (usually referred to simply as "sessions") with end users of, e.g., terminal equipment or with other VTAM applications (any of which is conventionally referred to as a "logical unit" or LU).
As illustrated in FIG. 4, the session-establishment process normally begins when a logical unit LU (shown in FIG. 4 as USER) sends a formatted signal to VTAM requesting that a session be established with a particular VTAM application (step (a), shown in FIG. 4 as LOGON REQUEST). If the VTAM application in question has signed in for work as described above, then VTAM "drives" the appropriate exit for that application. That is, VTAM passes control to the application's routine specified in the exit list EXLST (e.g., the LOGON exit routine) if any. This exit routine typically collects information about the session being established (referred to as a "pending" session until it is established) and returns control to VTAM. VTAM is thus freed up to process other exit routines, while the application can proceed with setting up formatted data storage areas, specific to the pending session, in accordance with VTAM conventions, and to perform other session-preparation work.
Among the formatted areas set up by the VTAM application in preparation for a new session is a "node initialization block" NIB. The NIB contains information to identify and define the session. It may contain a pointer to a special exit list EXLST, the exit routines of which override certain exit routines specified in the access method control block ACB as described above for the particular session. The node initialization block NIB also specifies the initial CONTINUE mode (ANY or SPECIFIC) for the session, explained in more detail in Section 1.4(e) below.
Eventually, assuming that the VTAM application is willing to establish the requested work session, the VTAM application advises VTAM that it has completed its session-establishment preparations, and that it is ready to begin the requested work session. It does so by issuing to VTAM an OPNDST (open destination) macro instruction. This macro instruction is accompanied by a pointer to a request parameter list RPL, which contains the address of the node initialization block to be used for the new session as well as other control information pertinent to the specific VTAM service desired by the application (in this case, completing a session-establishment request), e.g., a BIND argument and associated data relating to the proposed session.
VTAM processes the OPNDST macro instruction in part by assigning a unique communications identifier or "CID" to the session being established. The CID is VTAM's method of "tagging" each session for identification; it is used by VTAM as an index into a lookup table of session-information storage areas. VTAM informs the VTAM application of the CID by copying it to the CID field of the node initialization block NIB and/or to the ARG field of the request parameter list RPL, depending on the specific circumstance, as described in the VTAM Manual. The VTAM application thereafter uses the CID to identify the specific session in requesting services from VTAM.
Sending and Receiving Data via VTAM
After a session has been established between an end-user (a logical unit LU) and a VTAM application, the application can send data to or receive data from the LU, in either case doing so via VTAM's communications services. These services may be invoked by the application through the issuance of a SEND or RECEIVE macro instruction to VTAM. These macro instructions ("requests" for data transfers) may refer to (i) control information, specified by the application in the request parameter list RPL as described in Section 1.1(d) above; and optionally may refer to (ii) data to be transferred, normally stored in the VTAM application's addressable storage area.
Chains of Request/Response Units (RUs). Data is normally transferred between the application and VTAM in pieces no larger than a specified size. Each piece is referred to as a "request/response unit" or RU. The specified size of the RU is referred to as the RUSIZE and is normally determined by system programmers who operate and maintain the particular computer system in question. In many if not most systems, the RUSIZEs for incoming and outgoing data may be different.
If a VTAM application must transfer data larger than the RUSIZE, and the particular VTAM environment does not support the Large Message Performance Enhancement Outbound (LMPEO) RPL operand, then the APPL must first break the data stream into a chain of smaller request units or RUs. When the RUs in a chain are more than two in number, they are referred to respectively as first in chain (FIC), zero or more middle in chains (MIC), and last in chain (LIC). Depending on the amount of data to be transmitted, a chain may include only one RU (only-in-chain or OIC); a two-RU chain does not have a middle in chain RU. Several examples of RU chains are shown in FIG. 5.
SEND Requests from a VTAM Application. A SEND request is a request issued to VTAM by a VTAM application that wishes to transmit data and/or control information to a logical unit LU. The general flow of data and control information for a SEND request is illustrated in FIG. 6.
The VTAM application can specify, by including a RESPOND operand in the request parameter list RPL for the SEND request, whether and how the receiving LU should report back the successful or unsuccessful receipt and processing of that SEND request. A "definite response requested" notation in the RPL indicates that the receiving LU should report either successful receipt and processing (referred to as a "positive response") or unsuccessful receipt and processing (referred to as a "negative response"). An "exception response requested" notation in the RPL indicates that the receiving LU should report back only unsuccessful receipt and processing, i.e., only negative responses are desired.
SEND-request sequence numbers are assigned by VTAM (in the case of normal-flow requests) or by the VTAM application (in the case of expedited-flow requests). These sequence numbers help VTAM and/or the application correlate a receiving LU's success/no-success response with the SEND instruction that requested such a response.
Because VTAM acts as an intermediary between the sending VTAM application and the receiving logical unit LU, the VTAM application does not become aware of the LU's success/no-success response to the SEND request until notified by VTAM. In issuing a SEND request, the VTAM application can specify in the request parameter list RPL just how and when it is to be so notified. The RPL operand POST=RESP indicates to VTAM that the VTAM application wants to wait until this response is received before continuing its own execution. (In this case, the LU's response is copied by VTAM to the RPL, where it may be accessed by the VTAM application.) Alternatively, the RPL operand POST=SCHED indicates to VTAM that the VTAM application does not want to wait for the receiving LU's success/no-success response, and accordingly that VTAM is to notify the VTAM application as soon as VTAM has accepted the SEND request so that the VTAM application can proceed with its own execution.
RECEIVE Requests from a VTAM Application. A RECEIVE request is a request issued to VTAM by a VTAM application that is ready and wishes to receive data and/or control information from a logical unit LU. Each RECEIVE request includes a pointer to a request parameter list RPL, in which additional control information can be specified by the VTAM application. A VTAM application can have numerous RECEIVE requests pending simultaneously.
As shown in simplified form in FIG. 7 and in somewhat more detail in FIG. 8, VTAM collects RECEIVE requests from VTAM applications (shown as APPL in the figures). It also collects data from one or more users (e.g., terminal operators) or other logical units LU.
RECEIVE ANY vs. RECEIVE SPEC(ific). A VTAM application frequently has multiple sessions on-going at any given time, each session being identified by a CID as explained in Section 1.3. The application may wish to issue a RECEIVE request that is, or alternatively that is not, specific to any particular session.
FIGS. 7 and 8 show in simplified form the general flow of data and control information for a RECEIVE request. By specifying the operation code ANY in the request parameter list RPL for the RECEIVE request in question (OPTCD=ANY), the VTAM application can indicate to VTAM that VTAM can complete that RECEIVE request by giving the application incoming data intended for any session. Alternatively, the VTAM application can use the operation code SPEC (for specific) to indicate to VTAM that only data intended for a specified session can be used to complete that particular RECEIVE request.
CONTINUE ANY vs. CONTINUE SPEC(ific). Suppose that a VTAM application issues several RECEIVE ANY requests, and that soon thereafter VTAM completes one of these requests with a query from an end user operating a terminal (the terminal thus functioning as a logical unit LU, of course). Receipt of the query may touch off a conversation between a subroutine of the VTAM application and the end user LU. The subroutine might be one that is designed to handle the specific type of query send by the end user.
Such a conversation between the VTAM application's subroutine and the end user would take the form of a series of SEND and RECEIVE requests issued by the subroutine. The RECEIVE requests would include the operation code OPTCD=SPEC because the subroutine's interest in receiving data would extend only to the specific end user's session and not to any other session.
In this situation, a problem can arise if one of the other RECEIVE ANY requests remains pending (uncompleted) during this conversation. The subroutine may have issued its RECEIVE SPECIFIC requests to match its SEND requests in anticipation of getting specific information back from the end user in the conversation. If VTAM uses that specific information to complete the previously-pending RECEIVE ANY requests, however, the RECEIVE SPECIFIC requests might not be completed for a long time (more likely, the subroutine would eventually assume that an error had occurred).
The VTAM application can address this problem by specifying in its RECEIVE ANY requests that, upon completion of any one of these requests, VTAM should shift into RECEIVE SPECIFIC mode (i.e., suspend processing of RECEIVE ANY requests) for that particular session only until told otherwise. This may be done by including the operand "CONTINUE=SPEC" (for SPECIFIC) in the request parameter list RPL for each of the RECEIVE ANY requests.
If CONTINUE=SPEC is included in the example above, VTAM completes the first RECEIVE ANY request by delivering the end user's query to the VTAM application. Because of the CONTINUE=SPEC operand, however, VTAM at that point suspends processing RECEIVE ANY requests for that particular session.
Suppose now that the VTAM application's subroutine completes its handling of the end user's query by issuing a final SEND request (e.g., to report completion to the end user). The request parameter list RPL for this SEND command may include an operand CONTlNUE=ANY to cause VTAM to resume processing of RECEIVE ANY requests for that session.
As documented in the VTAM Manual, a session's CONTINUE ANY.vertline.SPEC mode is tracked separately for each of the three different types of RECEIVE input that are permissible under VTAM, namely DFSYN (for normal data flows), DFASY (for expedited data flows), and RESP (for responses).
VTAM Session Termination; CLOSE of APPL
A VTAM application can terminate a session between itself and another logical unit LU (e.g., an end user operating a terminal) by issuing a CLSDST (Close Destination) or TERMSESS (terminate session) macro instruction to VTAM. This macro instruction may include the CID of the session in question to help VTAM identify the proper session to be terminated.
When all of a VTAM application's on-going sessions have been terminated and the application no longer needs any VTAM communications services, the application can take itself off-line, so to speak, by issuing a CLOSE macro instruction to end its communications with VTAM.
Single Session Limitations on End Users
Up to this point, the discussion has been from the perspective of the VTAM application. A limitation of much of the "installed base" of terminal hardware and other peripheral devices is usefully described from the perspective of the end user, e.g., a person operating a terminal device (which device operates as a logical unit LU as noted above).
Many if not most existing device-type logical units do not support more than one session at a time. That is, such an LU cannot be "in session" with more than one VTAM application at a time; nor can such an LU engage in multiple sessions with a single VTAM application, even though the VTAM application itself can engage in multiple sessions with different LUs.
Prior attempts have been made to address this installed-base problem with "add-in" software. These prior attempts appear to have been less than satisfactory.
One prior approach may be referred to as the "CLSDST PASS" approach. Generally speaking, an end user desiring to use a VTAM application logs on instead to a special session manager VTAM application that displays a menu of available VTAM applications. When the user selects an item from the menu, the session manager application issues a CLSDST PASS macro instruction followed by a SIMLOGON to VTAM to cause VTAM to terminate the end user's session with the session manager and to pass the end user to a new session with the VTAM application selected from the menu. This approach has the advantages including simplicity and low overhead, and it provides some user flexibility in logging on to other VTAM applications, but it also has disadvantages including permitting only one session at a time.
Another prior approach may be referred to as the relay session manager approach. In that appproach, a session manager VTAM application establishes numerous access method control blocks ACB, thus fooling VTAM into believing that the session manager application is actually several distinct applications (referred to below as virtual applications). An end user may establish a VTAM session with one of these virtual applications in the usual way described above; the session manager application in turn may establish multiple sessions with other VTAM applications and link these sessions among the end users logged onto the virtual applications.
In effect, an end user under the relay session-manager approach goes into a single session with the session manager VTAM application. The session manager in turn establishes multiple sessions with other VTAM applications, as directed by the end user, and relays information between them. While this approach permits multiple sessions as well as centralized mapping-type optimization, the overhead costs can be dramatic (among other problems).
Mapping-Type Optimization with Input Suppression
The commonly-owned patents referred to above in Section 1 teach methods of performing mapping-type optimization coupled with input suppression. Very generally speaking, mapping-type optimization involves reducing the size of an outgoing data stream, i.e., one being routed from a VTAM application to a terminal or other logical unit LU, e.g., for display on a terminal buffer. Such an outgoing data stream may include instructions for unnecessary repainting of the terminal screen with, e.g., characters that are identical to the characters that are already present on the screen--to that extent wasting the resources used to route the outgoing data stream. Mapping-type optimization generally entails:
"Input suppression" takes advantage of the present-state map to override instructions from an APPL to a terminal or other LU to transmit certain portions of its buffer contents back to the APPL regardless whether those portions have actually changed. An APPL may include such an instruction, for a given field in a terminal's buffer, by pre-setting the modified data tag (MDT) in the field attribute byte for that field.
When the terminal's user hits the ENTER key (or equivalent command), the terminal's control software causes it to transmit a data stream that includes the contents of all fields whose MDTs are set. A field's MDT may be set by the terminal itself in response to editing of the field contents by the terminal user, or it may be pre-set by the APPL as mentioned in the previous paragraph. In the latter case, the field is referred to as "premodified field."
The incoming data stream generated by the terminal would thus include the contents of any fields whose MDTs were pre-set by the APPL (where the MDTs were not otherwise cleared, e.g., by the ERASE INPUT command), regardless whether those contents had actually been changed by the terminal user. This results in unnecessary network traffic.
When an updated-state map of a terminal's buffer contents are saved for later user in mapping-type optimization, the contents of premodified fields are already available and thus need not be re-sent by the terminal. Thus, pre-set MDTs can be cleared. Because the APPL is expecting the contents of the corresponding premodified fields to form part of the incoming data stream, however, those contents can be "spliced" into the data stream by copying from the previously-saved map. cl SUMMARY OF THE INVENTION
Under VTAM, or similar-type data communications system, co-executing "partner" processes typically exchange data via SEND and RECEIVE requests that are processed by VTAM. As described in detail in Sections 4.5 through 4.8 below, a method in accordance with the invention provides a means for optimizing this data exchange process. The optimized method bypasses VTAM to provide significant savings of system resources and improved execution speed over that required for VTAM to process the same SEND and RECEIVE requests.